meta: Add RELEASE.md #3224
meta: Add RELEASE.md #3224
Conversation
| 5. **Day 14:** Community announcement and gradual provisioners upgrade. | ||
| 6. **Day 16:** Deploy `rusk-vX.Y.Z` to **Mainnet**. |
There was a problem hiding this comment.
Isn't "provisioner upgrade" the same of "deploy to mainnet"?
What's the difference?
There was a problem hiding this comment.
Isn't "provisioner upgrade" the same of "deploy to mainnet"?
What's the difference?
People already deploying the binary, but thinking about it it doesn't make a whole lot of sense since we'll specify an upgrade is active after a given block height into the future anyway if it's a protocol change. Maybe it makes sense to specify a minimum amount of time/blocks a protocol change needs to be activated.
In terms of the dates mention, they're just examples. Feel free to suggest a different time frame.
| 1. **Unit Tests:** Every PR must pass. | ||
| 2. **Integration Tests:** Wallet, SDKs, contracts, circuits. | ||
| 3. **Network Tests:** Simulate large-scale node clusters. | ||
| 4. **Compatibility Tests:** Ensure backward compatibility with old node versions. |
There was a problem hiding this comment.
I would change "old node versions" to "previous cluster"
HDauven
requested review from
kieranhall,
welf,
ascartabelli,
miloszm,
fed-franz,
nortonandreev,
Daksh14,
moCello,
herr-seppia and
Neotamandua
| - **Devnet:** `X.Y.Z-rc` | ||
| - **Testnet:** `X.Y.Z-beta` |
There was a problem hiding this comment.
Shouldn't the Devnet serve as the beta environment and the Testnet act as the Release Candidate? Since the Release Candidate is expected to be more stable than the beta, it seems more logical for it to be deployed on the Testnet.
| - **Creation:** Every 1-3 months or as needed. | ||
| - **Hotfixes:** Created directly on the (affected) release branch. | ||
|
|
||
| --- |
There was a problem hiding this comment.
I personally see no purpose of these separators, just make the file more cluttered, when viewing as MD rather than raw text.
| - Summary of changes. | ||
| - Migration steps (if applicable). | ||
| - Framework upgrade details. | ||
| - **Changelog Management:** Use automated changelog generation from PR labels (`breaking-change`, `enhancement`, `bug-fix`). |
There was a problem hiding this comment.
Just a note – for Web Apps, @kieranhall has investigated automated changelog generation some time ago. However, seems like we couldn't find a solution that suits our needs, given the current way we do the change log.
We still quite often have merge conflicts, related to the changelog, so I am not against an automated solution. But we might need to discuss with the rest of the tech team and see if we can do something similar to what others are doing, so to integrate such solution for us too.
| - **Policy:** Updated weekly, deploying directly to the Devnet environment. | ||
|
|
||
| ### Release Branches (`rusk-release-vX.Y`) | ||
| - **Purpose:** Stable releases for mainnet or testnet deployments. |
There was a problem hiding this comment.
I am a bit confused, especially with the 7. Environment Versioning Policy stating that testnet is beta (well, I think it should be RC, see the comments there).
If so, testnet should be for the rc branches, while the mainnet for the stable branches (rusk-release-vX.Y) only, no?
Resolves #3223
This PR introduces a
RELEASE.mdoutlining a proposed release process for the Rusk monorepo. It covers branching, tagging conventions, a release lifecycle, testing phases and artifact publishing.